UDL Outline

December 21, 2006

This document describes some of the functionality that would make our materials "UDL." It describes a nice set of functions that provides a target to shoot for. It also suggests some terminology that would be nice to use for consistency.

The Instructional Material

A module is a set of instructional goals and a sequence of assignments. One of our two-week modules might have ~20 assignments. Some assignments have implicit or explicit assessments.
The instructional goals have links to state and national standards.
Each assignment has properties that a teacher can set for each student:

• Presentation. This controls how the assignment looks, whether sound is used, etc. The plan is that every software component will be smart enough to react automatically to high-level descriptions of the presentation.
• A type of scaffolding. This is where the variable cognitive level might come in. Five kinds of scaffolding are mentioned in the proposal. At each point in an activity that requires scaffolding, five different scaffolds would have to be authored.
  alternative versions These would be versions of the assignment that would be authored separately. This is how we would handle very different screen layouts that cannot be done automatically. It might also be used for prototyping. Also, different kinds of tests might be presented as alternative versions for the same assessment assignment.
• Student controls. The teacher could specify which of the above would be accessible to students. Perhaps there would be a menubar with available options shown as icons, as done in MW.
• Start and stop dates. that define when the assignment is available to the enrolled students. For our grades, this may be over-kill, but secondary teachers will like it.
• Use/omit. Would be a switch that would allow a teacher to skip a particular assignment.
• Weight. An integer that determines the relative weight of the grade of an assignment in the final grade for the module. Zero is allowed.

Each assignment has other properties set by its author:

• a name
• a pedagogical function (e.g. introduction, exploration)
• goals. A link, supplied by the authors to the module to the instructional goals addressed by the assignment.
• a content description
• optional embedded assessment
• optional explicit assessment

Student Monitoring

Student work is submitted for grading and saved for each assessment. Each item in an assessment would link to one or instructional goal for the module. Items in submitted assignments can be automatically graded if they require multiple-choice or a single word or number responses. If the assessment is implicit or a performance-based task, then the task generates a grade and description of the student actions. Submitted items that need to be graded are saved and presented later to the teacher for grading. These can be text, a drawing, an annotated picture, a model, or the saved state of any application (ideally).
Each assignment has properties for each student that are determined by student progress:

• a status for each student (not assigned / not begun / begun / completed)
  if it has assessment,
• a maximum score
• a grade for each student (not attempted / score)
  the presentation, type of scaffolding, and version used in the assignment.
• a link to student work (e.g. essay, answers, annotated pix)

Each version of an assignment covers the same content and pedagogical goal. Each alternative

• has a name
• has a descriptive title selected from a short list of names (e.g. high stimulus)
  can be internal (i.e. part of the system like TEEMSS or MW) or external

Teacher Controls

The project provides the goals and internal assignments, but teachers can easily add external assignments and new versions of existing assignments that involve activities outside the electronic material we provide, such as "go to this web page" or "read these pages". External links would not be supported early on.

Students can be grouped. Each group has a name and number. Teachers may want to group students that have the same assignment properties, possibly based IEPs or apparent similarities of learning styles.

Assignments can be grouped. Each group might have a name, such as "Introduction."

Reports and displays for teachers

A progress report would be a matrix with students or student groups on the left and assignments across the top. Each cell would show whether that student (or group) had started or completed the assignment, and what their score was. Clicking on a score reveals the student work.

An assignment assistant would permit the teacher to see and a glance and set the assignment properties for each student and each assignment. To simplify, the properties could be applied to all students, all selected students, all students in a group, or all students in selected groups. Properties could also be set for all students by selected assignments (e.g. set the start date for assignments 1-5 and 9).

An assignment report would list in sequence all assignment names and content descriptions (including multiple versions) in a module with their default dates.

Assignment grading assistant. Allows the teacher to see and grade easily each item submitted for a particular assessment. The assistant would optionally show the right answer or rubric supplied by the author. Also available would be the instructional goal linked to the item. The assistant would allow teachers to go through all the responses to one item at one sitting. Student names and UDL settings would be optional (some teachers might like to be 'blind' when they grade, others may feel they can give better feedback if they know who they are grading at all times.) The assistant would have a display that would show at a glance where there were submissions that need grading.

Grade report. Calculates the current grade as sum(grades*weights)/sum(weights), where the sum is over all graded assessments.

Student report. Shows the progress of an individual student. A full report gives the module instructional goals, the name and description of each assignment, grades, and current grade. Has links to the submitted student work and teacher grading. Can be printed or emailed to parent/guardian.

A teacher goes through the following steps to offer a module:

• Get authorization. The teacher would be vetted and given a user name and password. (Only required once.)
• Enroll students. Eventually, we'd like to fit into a SIP-compliant school MIS system. With our without it, the program needs to know who the kids are, and generate a user name and password for each student. (Only required once.)
• Launch. Create an instance of a module and link it to students.
  Set dates (optional). To simplify setting dates, the author would provide a suggested duration in days of each activity, so the teacher could generate default dates for every activity by setting the module start date. (A school calendar would be needed that shows vacation days.)
• Set assignment properties. Use the assignment matrix to give alternative treatments to students. Students who previously took a module would inherit the last settings used. New students would be given defaults provided by the authors. The teacher could change any of these defaults.

The Structure of Student Materials

An assignment is displayed as a sequence of linked pages. Each page consists of one or more rectangular screen objects in non-overlapping, fixed locations:

• Graphics. Pictures, drawings,
• Text boxes.
• Graphs.
• MW models.
• Action buttons. Navigation, student UDL controls if allowed. Access to scaffolding (help). a speed controller (sets the speed of speech (is this possible?) and models.)
• Assessment items. Several types:
  • Multiple choice
  • Matched response—numeric (numerical input must fall in a numerical range)
  • Matched response-- text (input must match an item in a list of text options)
  • Open response
• Concept mapper (optional—later)
• Sketch tool
• Equation boxes (optional—later)
• Other objects (optional—later)

All or most screen objects have:

• A "Talk" button that describes the object. For a few seconds after a "talk" is done, pressing the button again will get more detail. Graphs and models describe themselves.
• A "Help" button
• An "Expand" button that gives a full-screen version of the object.
• A "Snapshot" button that records the current appearance of the object. The snapshot can be annotated and captioned. Snaps are put into a gallery and into the lab notebook.

Screen objects can respond to:

• Brightness. On a 0-10 scale this sets hue and contrast. Some objects might also have marquee lights and flashing at high settings.
• Foreground color
• Background color.
• Size. Sets font size, line widths, icon size.
• A "Tip" input that turns on or off roll-over tips and whether they are spoken.